BBS Toolkit

home *** CD-ROM | disk | FTP | other *** search

/ BBS Toolkit / BBS Toolkit.iso / doors_2 / rds_v120.zip / RDSDOCEN.DOC < prev next >

Wrap

Text File | 1991-02-05 | 89KB | 1,897 lines

╔══════════════════════════════ ┌─────────────────┐ ║ RDS Remote Dos Shell │ D.I.S.P. │────┐ ║ For Bulletin Boards │ │░░░░│ ╟────────────────────────────── │ │░░░░│ ║ (c) 1991 Robert W.van Hoeven │ Dutch │░░░░│ ╟────────────────────────────── │ Independent │░░░░│ ║ Release : 1.20 │ ShareWare │░░░░│ ║ Rel.Date: 5th February 1991 │ Programmer│░░░░│ ╠══════════════════════════════ └─────────────────┘░░░░│ ║ | │░░░░░░░░░░░░░░░░░│ ║ │ RDS.EXE | └─────────────────┘ ║ │ RDS.CTL | ┌─────┐ | ║ │ | │░░░░░│ | ║ │ | └──┬──┘ | ║ │ Lines starting with '|' are | ┌────┴────┐ | ║ │ changes to release 1.10 !! ------││││││ ═══│------- ║ └─────────┘ ╠═══════════════════════════════ ║ Address: Robert W. van Hoeven ║ PO. Box 131 ║ 1170 AC Badhoevedorp ║ Nederland / Holland ╚═══════════════════════════════ ┌───────┬─────────────────────────────────────────────────────────────┐ │ 0 │ Table of contents │ └───────┴─────────────────────────────────────────────────────────────┘ 1 ---- General information 1.1 Copyrights and License Agreement 1.2 Newer versions and contacting the author 2 ---- Package description and requirements 2.1 Preface 2.2 Requirements 2.3 Included files 2.4 Introduction 2.5 Specifications 3 ---- Installation description 3.1 Installation 3.2 RDS.CTL 3.3 Available commands 3.4 Security │ 3.5 Macro's, expansion and command-stacking │ 3.6 Help file format 4 ---- Runtime information 4.1 While inside the RDS shell 4.2 LOG file 4.3 Errors 4.4 Specialized command-line options 5 ---- Version information and credits 5.1 The BETA-team 5.2 Credits 5.3 Version history 5.4 Copyright, Trademarks ┌───────┬─────────────────────────────────────────────────────────────┐ │ 1 │ General information │ └───────┴─────────────────────────────────────────────────────────────┘ 1.1 Copyrights and Licence Agreement ──────────────────────────────────── - Users of the RDS-package must accept this disclaimer of warranty: - The RDS-package is supplied as is. The author disclaims all warranties, expressed or implied, including, without limitation, the warranties of merchantability and of fitness for any purpose. The author assumes no liability for damages, direct or consequential, which may result from the use of the RDS-package; - The RDS-package is a "shareware program" and is provided at no charge to the user for evaluation. Feel free to share it with your friends, but please do not give it away altered or as part of another system. The essence of "user-supported" software is to provide personal computer users with quality software without high prices, and yet to provide incentive for programmers to continue to develop new products. - If you find this program useful and find that you are using and continue the use of the RDS-package after a 30 days trial period, you must register the RDS-package as described below; - Non-commercial can get a licence for the usage up to this release of the RDS-package for a small amount of money. Look into the details in REGISTER.RDS. For Non-commercial users there is a POSSIBILITY to submit to one of the special contracts as explained in the file REGISTER.RDS. - Commercial usage of RDS will cost somewhat more. Also, a so called 'closed' Bulletin Board System (a system where the user must pay direct to the SysOp to get full access) is has to pay more than a Non-commercial user. Both types of users should look into the details in REGISTER.RDS; - The registration of the RDS-package will licence ONE copy for use on any computer at any one time, as long as the usage confirms to the type of registration you have done (so NON-commercial usage when you have a non-commercial licence); - Anyone distributing the RDS-package for any kind of remuneration must first contact the Author at the address above for authorization. - You are encouraged to pass a copy of the RDS-package along to your friends for evaluation. Please encourage them to register their copy if they find that they can use it; - Support on RDS, when used in a non-commercial environment, is available by means of written letters or by entering the inter- national echomaol area DISP; - Problems and suggestions can be entered in the FidoNet <tm> Echomail conference <tm> called DISP (international). Entering this echo does not exclude you of the duty to register the RDS-package, though users who evaluate the product can enter the echo for questions; - The RDS-package, all programs, the documentation and support-files is copyrighted 1990 by Robert W. van Hoeven, PO. Box 131, Badhoevedorp 1170AC, Holland. All rights are reserved. You may copy this package for backup purposes. Also you may copy and share unmodified copies of the whole package, providing that the copyright notice is reproduced and included on all copies. Excluded from this statement are the support-files written by other authors. Please refer to the documentation of these programs for copyrights and licence agreements; - It is forbidden to modify, adapt, translate, reverse engineer, de- compile and/or disassemble the software in the RDS-package. Patching the medium at places that carry the software is seen as a program change and is also forbidden. It is forbidden to create a so called 'bypass' to skip the original introduction screens and delay. Also it is forbidden to use such a 'bypass' unless supplied by the author (Robert W. van Hoeven) himself; - Performing any of the illegal actions as stated in the previous lines, is a theft and no fair play to the author and, more important, to the registered users; - Bulletin Board Systems that distribute the RDS package can convert the WHOLE package to any archive-system they like but all original files must be included in the new archive. The RDS-package on the Bulletin Board can contain at the most 2 extra files. These files can only be a commercial for that Bulletin Board and/or validation data that is presented as a service to all users and shall have no other functions; - After the normal trial period of 30 days, you must register the soft- ware (see REGISTER.RDS) or you must remove it from your PC; - Comments, suggestions and bug reports are welcome and will be answered as soon I have the time to do so. You can send me a letter of leave a NetMail <tm> message named to Rob Van.hoeven (mind the point) on node 2:512/100 (RA Support, Monster, Holland, SysOp is Reinier de Groot). When you want to send me normal mail, address it to: Robert W. van Hoeven, PO. Box 131, 1171 AC Badhoevedorp, Holland; Also you can enter messages in the FidoNet <tm> DISP Echomail <tm> area; 1.2 Newer versions and contacting the author ──────────────────────────────────────────────────────────────────────── The newest version of RDS is always available at the DISP-HQ on node 2:512/100. RDS is also distributed thru a number of DISP support nodes. You can obtain RDS in four different ways: - Logging on at DISP-HQ or a support node All zones : 2:512/100 (Multiline Paradise NL ) DISP-HQ (Sysop: Reinier de Groot) For zone 1: 1:203/988 (Amber Shadow ) Support & beta (Sysop: Dave Overton ) For zone 2: 2:280/4 (Sirex NL ) Support & beta (Sysop: Gerry Ulrich ) 2:242/4 (GOLEM Meerbusch FRG ) Support & beta (Sysop: Hanstheo Wolf ) 2:244/12 (FunBoard Felbert FRG ) Support & beta (Sysop: Dirk Astrath ) The BBS's above will always have the most current version of RDS available. Also, in some cases, it is possible to request the newest RDS with a standard file-request (ask the SysOp in question). On 2:512/100 you can use RDSNEW as magical name to Freq. the newest version. The actual DISP-HQ is point 2:512/100.5, but this is a closed system and can not be accessed from the 'outside'). You CAN address netmail to this point though ! - Logging on to a SDS node RDS is distributed thru SDS/SDN, but only big minors (x.10, x.20 and so on) and majors (14.01, 15.01 and so on) are submitted to the SDS distribution point in Holland; - Logging on to your own BBS; Chances are, that you will find an older version (international users) because it will take some time for the new version to 'bleed' thru the net; - Update service; You can enter a special update service (read REGISTER.RDS). If you think you have found problems in RDS, or in any other case, you wish to contact the author, you can send me: - A letter to the address you can find in the header of this file; - A NetMail <tm> message to Rob Van.hoeven (please mind the point between Van and Hoeven) at 2:512/100 or (better) 2:512/100.5; - A Message in the FidoNet <tm> DISP echomail <tm> area; ┌───────┬─────────────────────────────────────────────────────────────┐ │ 2 │ Package description and requirements │ └───────┴─────────────────────────────────────────────────────────────┘ 2.1 Preface ──────────────────────────────────────────────────────────────────────── Please notice the following: - RDS is a ShareWare product in every right way, this means this software is not crippled in any way. There are only some changes to the registered version but the only have to do with cosmetic changes (no delays, your (BBS) name in the start-up header and so on); 2.2 Requirements ──────────────────────────────────────────────────────────────────────── RDS requires: - PC XT/AT/386 - At least 180K free memory under the BBS; - DOS 3.xx or higher; - HDU optional - A full functional BBS with an exit to doors. RDS 'knows' specifically about Remote Access <tm> but can run under any BBS that creates the files EXITINFO.BBS and DORINFO1.DEF. Even when the BBS does not create such files, you could use a conversion tool that creates these files for you (look into the BBS-area's on the bigger boards); 2.3 Included files ──────────────────────────────────────────────────────────────────────── The package includes : RDS.EXE The main program RDS.CTL A sample RDS.CTL file RDS.ANS A sample file for KILLNICE │ RDS.HLP Help file Documentation 2.4 Introduction ──────────────────────────────────────────────────────────────────────── Many SysOp's struggle with specialized doors to get REMOTE (and local) access to DOS functions. Most of these SysOp's will only use the normal DOS-commands when working in such a door when they use such a door as a maintenance door for them self (when being remote) or their Co-Sysop (this 'creature' or 'creatures' are almost always remote <grin>). To give remote access to yourself or the Co-Sysop(s) means you have to implement special functions/doors. Some of these doors give you the access to normal programs (even when they normally could not work remote) but most of the time, this is not what you (or your 'Co') needs. Also there are some major drawbacks to any type of 'real-dos' doors: - Some of these doors (Gateway alike doors, batch-files with CTTY com- mands and so on) can NOT access most of the normal programs, because these programs do direct screen access (not to be displayed while working remote) and keyboard access, not to be captured from a re- mote session, thus forcing a 'hangup' (you can't 'see' a thing and you can't enter a key even when you know the combinations). This problem is 'captured' with a carrier-watchdog, thus forcing a re- boot when you hang-up the phone and also taking all other users down with you (when running multiple lines in one machine) or forcing a hangup (some combinations of multitasking software and a reboot cause hangups); - Some doors can access normal programs that are not covered by the previously mentioned doors. But in multitasking environments, these functions are dangerous and can (still) cause hangups. Also the re- mote site should use a 'doorway-mode' in the software otherwise serious damage to the fingers (and brains for that matter) could occur. Most of the supplied features are never needed and should (in fact) be kept away from your 'Co'; - Normal DOS-doors don't have BBS-specific functions like those implemented for Remote Access <tm>; If you need special programs to run remote (not DOS-commands, but real programs, some DOS-commands are real programs for that matter, but still) and these programs have nothing to do with DOS-commands and/or some specialized BBS-features, RDS will not be your taste of door. If you want a FULLY secured access to most of the normal DOS- commands (please read the chapter about security) AND something more, RDS could be worth trying, 2.5 Specifications ──────────────────────────────────────────────────────────────────────── Those who took the time to read the introduction will have a general picture of RDS. A brief summary of the functions: RDS can: - Give access to most DOS-commands without entering DOS itself, thus creating a fully controlled (carrier!), secured (read on!) and com- patible DOS-environment; - Give all the normal DOS-commands (DIR, DEL, REN, MOVE, COPY, CD, RD MD, drive switching, VER, MEM, TYPE and so on), some of them being an extension to DOS (MEM and MOVE); - Control all access to RDS (based on the name of the user) and control all access inside RDS (based on drives, directories and files); - In fact, give ANY normal user the (controlled) access to DOS- commands you specify and only for files, drives and directories you allow. The next version after 1.01 (to be released soon) will give you simple tools to configure such an environment without entering all users yourself; - Make use of a subset of commands specialized for Remote Access and a special subset of generalized commands that can be used while being remote; - Make use of special BBS commands like Upload and Download, controlled with RDS security and available at any place while inside RDS; - Suit your needs. The only thing you have to do is to enter a message with suggestions you have and features you would like to see in RDS and maybe you'll see these features in the next release; - Can call any program you like, but it is not possible to call a program that needs input during its execution; What RDS can't now, but can do soon: - Simple FILES.BBS changing with some FILES.BBS editing functions; - Access to DOS-programs like SUBST, ATTRIB, CHKDSK and so on, still keeping control; - Access normal compressor programs like PKZIP, ARC, PAK, LHARC and so on. These will be run 'under' RDS-control; What RDS can't: - Executing 'normal' programs like your compiler, full-screen editor, mind-blowing arcade games and so on. For this functions you need a real DOS-door on your system IF this program needs input or writes its output directly to the screen-buffer AND you need to see this output; - FORMAT. It will never support such a function, it is to big a risk to implement such functions. Mostly it is up to you as a user, to keep on giving suggestions. RDS is a modular program. Implementing functions is (relative) easy if they are straight-forward. Something like 'Let RDS talk to me' will take some time <grin>. For all its functions RDS 'leans' heavily on it's own control-file. ┌───────┬─────────────────────────────────────────────────────────────┐ │ 3 │ Installation description │ └───────┴─────────────────────────────────────────────────────────────┘ 3.1 Installation ──────────────────────────────────────────────────────────────────────── People who think that installing RDS is difficult should consider to read a DOS-manual. If you can install a BBS (and you did that, I ima- gine), you can install RDS ! If you have any problems with the installation than enter a message in the DISP echomail area or send me a NetMail message. I can read, speak and write English, German and Dutch. Now for the installation itself. I'll use an installation in a Remote Access environment. QuickBBS <tm> users should also have no problems, other BBS-types could need special programs to create the EXITINFO.BBS and DORINFO1.DEF files and their structures. - Place RDS.EXE in some directory; │- Place RDS.HLP in the same directory (or somewhere else) as the │ RDS.EXE file. You can use RDS.CTL parameter to point to the │ RDS.HLP file. If you still use a version 1.10 or less and you │ have translated all *.RDS (old 1.10 and earlier versions HELP │ files) to your own format, you should read the CONVHELP.RDS │ file for details; - Create a RDS.CTL (or alike) file. This can be done in several ways: - Under the name RDS.CTL in the directory where RDS.EXE is stored (when running under DOS 3.xx or higher); - Under the name RDS.CTL somewhere in the DOS-path (DOS 2.xx and up); - Under the name RDS.CTL in the directory that is CURRENT when your BBS executes a door program; - Under the name RDS.CTL in any directory, provided you create a variable in the DOS-environment with the format: RDS=[drive][directory]\RDS.CTL or RDS=[drive][directory]\ - Under any name, anywhere, provided you create a variable in the DOS-environment with the format: RDS=[drive][directory]\[name_of_your_CTL] Below is a description of what you can (or must) enter in the RDS.CTL file; - Create a type 7/15 menu entry in your BBS with some security level. Use the following call to RDS in the data-field: [drive][directory]\RDS.EXE RDS now has some command-line options to consider. Please read chapter xx.xx about the functions and how to implement them ! RDS does not need (or knows about) any command-line option. Use the *M option in a Remote Access environment when you can (look into the DOX) or call RDS from a type 15 when memory is low. RDS uses between 110K and 180K under your BBS (depending on the functions you want to support). Other BBS types should use a 'exit from BBS' like the type 15 in RA and QuickBBS; - Edit the file RDS.ASC to a format you like (if you want to use the command KILLNICE) and place it somewhere in a directory; - Everything is ready to run. Try RDS yourself (local) first before your users are frustrated over a menu they can call and that seems to do nothing. Work away all errors and let it go loose for a remote job ! That's all there is to. The first part is done. Now take some time to create the CTL-file. 3.2 RDS.CTL ──────────────────────────────────────────────────────────────────────── The RDS.CTL file is a normal text-file (ASCII-file). You can create this file with program's like EDLIN or any other ASCII-editor. RDS.CTL must be in the DOS-path (DOS 2.xx) or in the same directory as RDS.EXE (DOS 3.xx). Also it is possible to access the RDS control-file in the following ways: - The usage of an environment variable RDS 1) When the value of this variable terminates with a backslash (\), RDS assumes the value is a path and adds RDS.CTL to the variable and searches for this file; 2) When the value of this variable does NOT terminate with a back- slash (\), RDS assumes that the variable is a full path and name to the control-file and RDS will try to find it; - The usage of the /CTL[drive:][path][name] option. RDS will search for the supplied filename on the supplied drive and in the supplied directory; RDS.CTL contains many options. Some of them optional, some of them not. The general format for the RDS.CTL file is: Option {parameter} {parameter} ..... {parameter} There are NO restrictions to the position you start the command, nor the starting position of the (optional) parameters, but the 'option' and (if present) the 'parameters' have to be separated with one or more spaces. You can make any mixture of upper and lower case ! A generalized example of RDS.CTL is included in the release-file. It contains ALL options available in this release. RDS.CTL can (or must) contain the following statements: ┌─────────────────────────────────────────────────────────────────────┐ │ RegistrationName [name] │ └─────────────────────────────────────────────────────────────────────┘ │Usage : This option has only a meaning when you received a key after │ you registered RDS. You can not use it when you are using RDS │ in the (unregistered) trial period; Relate: None │┌─────────────────────────────────────────────────────────────────────┐ ││ RegistrationKey [key] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : This option is now obsolete and should (must) be removed from │ RDS.CTL. Registered users, please read the REG_USER.RDS file. ┌─────────────────────────────────────────────────────────────────────┐ │ BBSType RA|QBBS │ └─────────────────────────────────────────────────────────────────────┘ Usage : This parameter is mandatory. You must supply RA or QBBS even if you don't use the RA or QuickBBS programs but a compatible BBS. The difference between RA and QBBS is, that with RA, you get the RA subset (useless when not running under RA) and with QBBS these commands are not present. Relate: BBSDirectory ┌─────────────────────────────────────────────────────────────────────┐ │ BBSDirectory [path] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This option is only needed (and mandatory) when you supplied the 'BBSType RA' option. [path] must point to the Remote Access system directory. This is the directory containing CONFIG.RA, USERON.BBS and so on. RDS will check if the directory is valid and contains the file CONFIG.RA. Relate: BBSType ┌─────────────────────────────────────────────────────────────────────┐ │ BBSWorkDirectory [path] │ └─────────────────────────────────────────────────────────────────────┘ Usage : If, for any reason, you want RDS to point to a specific directory containing EXITINFO.BBS and DORINFO1.DEF, you need this option to point to that directory. Normally RDS will look in the BBSPath directory (QBBS) or in the CURRENT di- rectory (RA) for these files. Relate: BBSType │┌─────────────────────────────────────────────────────────────────────┐ ││ HelpDirectory [path] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : This option can point to a directory containing RDS.HLP or │ it can point (with a complete path) to this type of file with │ an alternate name. │ C:\ZIP\ will tell RDS to look for RDS.HLP in C:\ZIP │ C:\ZIP\MYHELP.OWN will tell RDS to look for MYHELP.OWN in │ C:\ZIP │ │Relate: None │┌─────────────────────────────────────────────────────────────────────┐ ││ MacroExpandBuffer [number] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : RDS (from 1.20 and up) contains two statements that can stack │ (generated in case of EXPAND) statements on RDS's own command- │ stack. The stack has a default size of 100 entries, resulting │ in 25600 bytes of memory consumption. If this is to many for │ you and you will never stack that much statements, you can │ lower the stack to a minimum of 10 (resulting in 2560 bytes │ of overhead) but remember this. When you use EXPAND for exam- │ ple in the case of EXPAND COPY *.* C:\TUP (copy all files in │ the current directory to C:\TUP) and your current directory │ contains 200 files, stacking will be impossible when you │ don't have a stack of at least 200 lines. MacroExpandBuffer │ can be set anywhere between 10 and 1000. The bigger, the more │ files can be EXPAND'ed or MACRO-files can be bigger. Tradeoff │ is the memory consumption. 256 bytes-per-line of memory are │ lost, so 1000 lines will mean 256K ! │ │Relate: None ┌─────────────────────────────────────────────────────────────────────┐ │ DSZ [path to DSZ] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This option must be present when you want to use the UPLOAD and DOWNLOAD commands under RDS. [path to DSZ] must be the fully specified path AND filename of DSZ. You can use both the COM and EXE versions, but RDS is only tested with the COM version ! Relate: DSZParm ┌─────────────────────────────────────────────────────────────────────┐ │ DSZParm [path to DSZ] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This option must be present when you want specialized para- meters for DSZ. By default RDS adds 'pB4096 ha both -m' to the sequence of DSZ parameters. If this is not right for your implementation, you can add your own options. In this case you must supply the DSZParm option with all DSZ options that YOU like (or want, or need). Relate: DSZ ┌─────────────────────────────────────────────────────────────────────┐ │ RADownText [file] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This option is only valid when you run a Remote Access BBS. [file] is a fully specified (and existing) filename of a file that contains the text that is displayed to the user when you force a Remote Access session down with the KILLNICE option. Relate: BBSType ┌─────────────────────────────────────────────────────────────────────┐ │ LogPath [path] │ │ LogPath [full path & filename] │ │ LogPath CURRENT │ │ LogPath CURRENT [name] │ └─────────────────────────────────────────────────────────────────────┘ Usage : When you want RDS to create a log, you MUST include the path to the log-file RDS will create. If this option is NOT present, no log is created. You must supply a valid path (please, with drive). RDS will create RDS.LOG inside this directory ! If you want a log with a name of your own, or you want RDS to add its log-records to an already present log-file (this could be the log-file of a Mailer or a BBS program), you can use the second option. In this case you must supply not only the path, but also the name of the log-file. If the log-file is not present, RDS will create it, otherwise RDS will append to this file. If you want RDS to create RDS.LOG in the CURRENT directory, use the third option. In this case the log is called RDS.LOG and this option should be used in multiline/network environ- ments; If you want RDS to create a log with a user-supplied name in the current directory, use the fourth option. In this case [name] will be created in the CURRENT directory. With the LogStyleFormat option, you can create your own log-file format, so appending to a Mailer-log or BBS-log could be done in a neat way ! RDS opens AND closes the log-file with every access. The access is under control of SHARE (if this program is present in the system). If another task or program has opened the log in a way that RDS's access is denied (sharing violation), RDS will wait up to 30 seconds (30 retries). If after 30 retries, RDS is still unable to write to the log-file, logging of the cur- rent action is denied. The action itself is completed. At the next action, RDS will try again. The RDS-user is informed of the waiting (every second or so), so she/he won't hang the line by mistake. RDS will (when logging is on) log ALL actions in detail. This is a handy feature when you want to 'reconstruct' any errors that have occurred after someone has used RDS. Please also look into the chapter about security ! Relate: LogStyleFormat ┌─────────────────────────────────────────────────────────────────────┐ │ LogStyleFormat [string] │ └─────────────────────────────────────────────────────────────────────┘ Usage : RDS creates several log-records under different conditions. You can use the standard log, but Sysop's hate all these different log-files (in general). RDS can create customized log-records. With these options, you can instruct RDS to create records that look the same as the records from your mailer or BBS program. The option LogStyleFormat and the LogDateFormat/LogTimeFormat combination can be used to define the style of the log-records RDS will create for ALL three log-files (normal log-file, error log-file and password-list log-file). These options are implemented with the idea that different log-styles only vary at the start of the records and not at the end. The LogStyleFormat defines the 'structure' of the log-record header. The format is free but with three special cases: - Blanks must be replaced by underscore characters '_'; - The part of the record that contains the date must be defined with %D (if a date is wanted); - The part of the record that contains the time must be defined with %T (if a time is wanted); - Any extra CRLF combinations (to create a separation line) must be defined with ^M; An example (also read LogDateFormat and LogTimeFormat for a description of the time and date functions): You want to create records that look like this: + 6 Jan 1990 2:00p The start of the log The 'The start of the log' part is constructed by RDS itself, so you have only to define the header. This is done as follows: LogStyleFormat +_%D__%T___ (The _ character replaces a blank) LogDateFormat DD_nnn_yyyy LogTimeFormat HH:mmt %D and %T are replaced by RDS with the date and time formats as supplied in LogDateFormat and LogTimeFormat. RDS.CTL contains a number of examples for the various BBS programs and Mailer programs. Relate: LogStartStyleFormat, LogDateFormat, LogTimeFormat ┌─────────────────────────────────────────────────────────────────────┐ │ LogStartStyleFormat [string] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This is an additional option you can use along with the pre- vious LogStyleFormat option. Some types of log use a special format where the actual date is put into an extra record (with- out any further meaning than logging the date). RDS can create such a record for you. RDS will put the record with the format you supply in LogStartStyleFormat into the log as the first and only record for THIS run of RDS. If RDS stops and is started again, a new record of this type is written. A type of log with this format is found in the FrontDoor <tm> mailer. The options you can use in this logstyle-format are the same as with the LogStyleFormat option. Relate: LogStyleFormat, LogDateFormat, LogTimeFormat ┌─────────────────────────────────────────────────────────────────────┐ │ LogDateFormat [string] │ └─────────────────────────────────────────────────────────────────────┘ Usage : LogDateFormat is used to define the 'date part' (actually the %D) in the LogStyleFormat option. RDS (in fact some nifty routines from TurboPower, credit to those who should have the credits) has knowledge of a big number of options to define the date. The [string] must be composed of a number special letters and (optionally) the separators and spaces between the various parts of actual date. In fact [string] should be a picture mask. The following characters have a meaning in the mask: m or M The month (upper case will create leading a leading space as replacement for a zero) d or D The day (upper case will create leading a leading space as replacement for a zero) y or Y The year (upper case will create leading a leading space as replacement for a zero) n or N The name of the month (upper case will force an upper case name); w or W The name of the day (upper case will force an upper case name); Each character must be repeated as many times as you want digits or letters. So '90' for the year 1990 is defined with yy and the full year is defined with yyyy. Some examples: mm/dd/yy 01-31-90 MM/dd/yy 1-31-90 dd/mm/yyyy 31-01-1990 dd/mm/yyyy 31-01-1990 dd NNN yyyy 31 JAN 1990 dd nnn yy 31 Jan 1990 dd n yyyy 31 J 1990 www dd nnn yyyy Sun 31 Jan 1990 As you can see, lots to experiment with. Relate: LogStyleFormat, LogTimeFormat ┌─────────────────────────────────────────────────────────────────────┐ │ LogTimeFormat [string] │ └─────────────────────────────────────────────────────────────────────┘ Usage : LogTimeFormat is used to define the 'time part' (actually the %T) in the LogStyleFormat option. RDS (in fact some nifty routines from TurboPower, credit to those who should have the credits) has knowledge of a big number of options to define the time. The [string] must be composed of a number special letters and (optionally) the separators and spaces between the various parts of actual date. In fact [string] should be a picture mask. The following characters have a meaning in the mask: h or H The hour (upper case will create leading a leading space as replacement for a zero) m or M The minute (upper case will create leading a leading space as replacement for a zero) s or S The seconds (upper case will create leading a leading space as replacement for a zero) t or T 'p'/'P' (in PM) or 'a'/'A' (in AM) e or E 'm'/'M' (in PM or AM) Each character must be repeated as many times as you want digits or letters. For h/H/m/M/s/S this should be two digits to be useful. Some examples: hh:mm 14:00 hh:mmt 02:00p HH:mmte 2:00pm HH:mm:ss 14:00:45 hh:mm:ss 14:00:45 Again, as you can see, lots to experiment with. Relate: LogStyleFormat, LogDateFormat ┌─────────────────────────────────────────────────────────────────────┐ │ USER [name of the user as it appears in EXITINFO.BBS] │ └─────────────────────────────────────────────────────────────────────┘ Usage : Now the difficult part. The User option is the start of a block (cluster) of secondary commands that can be used in a different way for every single user you allow to use RDS. The cluster MUST start with the USER option and the cluster MUST end with the USEREND option. Between USER and USEREND you can place various sub-options that are only valid inside the cluster (within the bounds of USER and USEREND). There can be as many USER/USEREND clusters as you like. RDS will only use (and store) the information for the current users. The only limits you have are disk-space and time. Time is an important thing to consider. RDS must 'struggle' thru every cluster when the door is started for a certain user. In a future release I will also supply a default set to be used by all users who have access to the door. The USER option carries 1 parameter. This is the name of the user who is allowed to enter RDS. If the RDS.CTL file also contains a USER ALL option, the options supplied in USER ALL are reset and the options for that specific user is used instead. The name must be in the same format as it appears in the EXITINFO.BBS (in my case Rob Van.hoeven, case is not impor- tant) file. As said earlier. If you allow more than one user (lets say the Sysop and the CoSysop), you must define a cluster, starting with USER and ending with USEREND, for each user. In the supplied RDS.CTL is an example of several users who are allowed to go into the door. The USER ALL option is a special case. If you want to allow ALL your users (with the right security level) into RDS with (minimal) options, you can supply a USER ALL cluster. The values inside the USER ALL cluster are used when there is NO specific cluster for the user in question available in RDS.CTL. Relate: UserEnd and all sub-options ┌─────────────────────────────────────────────────────────────────────┐ │ UserEnd │ └─────────────────────────────────────────────────────────────────────┘ Usage : Look into the description of the User option. A cluster for a certain user MUST end with UserEnd. UserEnd has NO secondary parameters. UserEnd must be preceded with (at least) a USER option and (optional) some secondary options between USER and USEREND. Relate: User and all sub options ┌───────────────────────────────────────────────────────────┐ │ UserPassword [password] │ SUBTYPE └───────────────────────────────────────────────────────────┘ Usage : This option is a sub-option and must be coded between a USER and USEREND option. It can not be used as a stand-alone option. This option is used as an extra security block for one or more of your users. When you supply this option with a password (length from 1 to 8 bytes), the user on the USER option MUST enter this password within 3 tries, otherwise access is denied. This option can also be used within the USER ALL cluster (if you have used that cluster). ┌───────────────────────────────────────────────────────────┐ │ UserDirectory [directory] │ SUBTYPE └───────────────────────────────────────────────────────────┘ Usage : By default, RDS will start in the CURRENT directory. If you do not want this, you can supply a start-up directory for every single user and/or in the USER ALL cluster. If you protect your C:-drive and the CURRENT directory is somewhere in C:, the user must ALLWAYS change to another drive or directory before any access can be done. If you supply an accessable directory as the default directory, the user does not have to change to this directory by them selfs. This option can also be used within the USER ALL cluster (if you have used that cluster). ┌───────────────────────────────────────────────────────────┐ │ ExcludeFile [mask] │ SUBTYPE └───────────────────────────────────────────────────────────┘ Usage : This option is a sub-option and must be coded between a USER and USEREND option. It can not be used as a stand-alone option. This option is only in effect for the user that you coded on the USER option belonging to the cluster where this option will appear. The ExcludeFile option will give you a method to deny access to a file or files you supply in the parameter. [mask] can be a single filename but also a filename with wildcards. You can supply up to 100 ExcludeFile options PER user. An example: User Rob van.hoeven ExcludeFile *.ZIP ExcludeFile *.COM .. .. UserEnd In this example, user 'Rob van.hoeven' can not access the files with the extensions ZIP and COM. These files will be displayed in a DIR but all manipulations (DEL, MOVE, COPY, RENAME, TYPE and so on) are denied ! ┌───────────────────────────────────────────────────────────┐ │ ExcludeDirectory [directory] │ SUBTYPE └───────────────────────────────────────────────────────────┘ Usage : This option is a sub-option and must be coded between a USER and USEREND option. It can not be used as a stand-alone option. This option is only in effect for the user that you coded on the USER option belonging to the cluster where this option will appear. The ExcludeDirectory option will give you a method to deny access to a directory you supply in the parameter. [directory] must be a fully specified name of a directory (so you MUST include the drive-letter). You can supply up to 100 ExcludeDirectory options PER user. An example: User Rob van.hoeven ExcludeDirectory C:\ZIP ExcludeDirectory C:\BBS\RAX .. .. UserEnd In this example, user 'Rob van.hoeven' can not access the directories C:\ZIP and C:\BBS\RAX. These files will be displayed in a DIR but you can not display the directories (with a DIR) itself, nor can you ChDir to them, remove them or even make them (if they weren't there at all). File access from and to these directories is denied (DEL, REN, MOVE, COPY, TYPE and so on) if this was not already the case (because of ExcludeFile and/or ExcludeDrive). ┌───────────────────────────────────────────────────────────┐ │ ExcludeDrive [drive:] │ SUBTYPE └───────────────────────────────────────────────────────────┘ Usage : This option is a sub-option and must be coded between a USER and USEREND option. It can not be used as a stand-alone option. This option is only in effect for the user that you coded on the USER option belonging to the cluster where this option will appear. The ExcludeDrive option will give you a method to deny access to a whole drive you supply in the parameter. [drive:] must be a normal drive-letter like A:, C: and so on. You can supply up to 26 ExcludeDrive options PER user. An example: User Rob van.hoeven ExcludeDrive C: ExcludeDrive A: .. .. UserEnd In this example, user 'Rob van.hoeven' can not access the drives A: and C:. File access from and to these drives is denied (DEL, DIR, REN, MOVE, COPY, TYPE and so on) if this was not already the case (because of ExcludeFile and/or ExcludeDrive). ┌───────────────────────────────────────────────────────────┐ │ NoDrive │ SUBTYPE │ NoCls │ SUBTYPE │ NoMem │ SUBTYPE │ NoUserOn │ SUBTYPE │ NoVer │ SUBTYPE │ NoDate │ SUBTYPE │ NoTime │ SUBTYPE │ NoDir │ SUBTYPE │ NoCD │ SUBTYPE │ NoRD │ SUBTYPE │ NoMD │ SUBTYPE │ NoDel │ SUBTYPE │ NoRen │ SUBTYPE │ NoType │ SUBTYPE │ NoRType │ SUBTYPE │ NoCopy │ SUBTYPE │ NoMove │ SUBTYPE │ NoKillNice │ SUBTYPE │ NoKillForce │ SUBTYPE │ NoBoot │ SUBTYPE │ NoViewArc │ SUBTYPE │ NoUpload │ SUBTYPE │ NoDownload │ SUBTYPE │ NoChat │ SUBTYPE │ NoBeep │ SUBTYPE │ NoLog │ SUBTYPE │ NoWhere │ SUBTYPE ││ NoExpand │ SUBTYPE ││ NoMacro │ SUBTYPE │ Shell │ SUBTYPE └───────────────────────────────────────────────────────────┘ Usage : This option is a sub-option and must be coded between a USER and USEREND option. It can not be used as a stand-alone option. This option is only in effect for the user that you coded on the USER option belonging to the cluster where this option will appear. Each of these options will deny a feature (or command) for this user. They have the following meaning: NoDrive User can not give C:, D: and so on; NoCls User can not give CLS NoMem User can not give MEM NoUserOn User can not give USERON NoVer User can not give VER NoDate User can not give DATE NoTime User can not give TIME NoDir User can not give DIR NoCD User can not give CD or ChDir NoRD ,, ,, ,, ,, RD or RmDir NoMD ,, ,, ,, ,, MD or MkDir NoDel User can not give DEL or ERASE NoRen User can not give REN or RENAME NoType User can not give TYPE or LIST NoRType User can not give RTYPE or RLIST NoCopy User can not give COPY NoMove User can not give MOVE NoKillNice User can not use KILLNICE NoKillForce User can not use KILLFORCE NoBoot User can not use BOOT NoViewArc User can not use VIEWARC NoUpload User can not use UPLOAD NoDownload User can not use DOWNLOAD NoChat User can not use CHAT (but still receive messages) NoBeep User can not use BEEP NoLog User can not use LOG NoWhere User can not use WHERE NoExpand User can not use EXPAND NoMacro User can not use MACRO Shell User can use SHELL. The default is NOSHELL !! An example: User Rob van.hoeven NoMEM NoMOVE NoCOPY NoDEL NOREN UserEnd In this example, user 'Rob van.hoeven' can not manipulate files because MOVE, COPY, DEL and REN will not work. Also a display of memory (MEM) will not work. Included in the package is a sample RDS.CTL with a number of users (names do not match real persons <grin>) and what they can or can't do with RDS. 3.3 Available commands ──────────────────────────────────────────────────────────────────────── Depending on the USER ... USEREND option for that user, the following DOS-commands are available: HELP See below DIR A full color directory with pause COPY A copy of a file MOVE A move of a file TYPE or LIST A type of a file RTYPE or RLIST A type of a file but from bottom to start (reversed) REN or RENAME A rename of a file DEL or ERASE A delete of a file CLS Clear the screen MEM See below VER Version of DOS (and 4Dos if present) DATE Get and set system-date TIME Get and set system-time CD Change to a directory. This is in fact a CDD. If you supply a drive along with the path, the drive is also switched; MD Make a directory RD Remove a directory x: Where 'x' is a drive letter. Switch to this drive; EXIT Terminate RDS USERON See below KILLNICE See below KILLFORCE See below BOOT See below VIEWARC See below UPLOAD See below DOWNLOAD See below CHAT See below TIMELEFT See below BEEP See below LOG See below WHERE See below SHELL See below Most of these commands are known to anyone who ever worked with DOS directly. There are a few specific enhancements to the normal subset of DOS-commands. These are: HELP ------------- You can use HELP in two ways. First you can use HELP without options and you will get a small list with available commands. Second, you can use HELP with a command (like HELP DIR or HELP MOVE) and you will get a screen full of help info on this specific command (only when the Sysop has implemented all *.RDS files). MEM ------------- MEM will give you a display with memory information. The display is made up with four different parts: - Conventional memory The available and total conventional memory in the PC - Expanded memory The available and total expanded (EMS) memory in the PC (if any) - Extended memory The available and total extended (above the 1024K) memory (if any) - XMS memory The available and total memory that is accessed by the XMS driver; Depending on the type of machine and the type of memory drivers you have, some or more values can be ignored. In some machines with QEMM (like mine) and extended memory available, RDS will report that there is no extended memory available. This memory is shared with the num- ber of bytes of XMS memory. USERON ------------- This command will only work when you specified the BBSType option as being RA. If this is the case, USERON will give a display of all available RA-lines and their status. Displayed are the names of the users being online, their baud-rate and if they have the 'Do not disturb' option ON or OFF. KILLNICE ------------- This command will only work when you specified the BBSType option as being RA and if you supplied a RADOWNTEXT option in RDS.CTL. This being the case, KILLNICE is able to terminate a user in some line. The format you must use is 'KILLNICE [linenumber]'. After entering such a command (lets say for line 3), RDS will copy the file sup- plied in the RADOWNTEXT option to NODExx.RA (in this case NODE03.RA) and will add a 'hangup' sequence after the file. Once in a while, the BBS will look to see if a NODExx.RA is present and will display the text to that user and force the line down. This is not the case when a user is inside a door or an external protocol. You can check if this is the case by giving USERON after 15-20 seconds. If the user is still online, you can be sure she/he is somewhere in a shell. In this case you must use stronger options (KILLFORCE). As you should have understood by now, this command has only meaning in a MULTI-LINE environment where the multiple lines are running on the SAME machine. KILLFORCE ------------- This command will work in any type of BBS. If you want to remove a user from another line and you can not use KILLNICE or KILLNICE has no effect (doors and so on, see above), you can enter the KILLFORCE command. The format is 'KILLFORCE [comport]'. This option needs some knowledge about the system. You must know the COM-port of a given line and supply it to KILLFORCE (NOT !! the FOSSIL-port). KILLFORCE will lower the DTR and RTS of the given COM-port. This is done thru the BIOS and not with ASYNCH communications. In fact, the KILLFORCE command blows the given COM-port sky-high for a moment. This can result in a nice bunch of garbage on the remote side because every type of synchronization is gone, but it will damage nothing and it does what you want (the user IS gone). As you should have understood by now, this command has only meaning in a MULTI-LINE environment where the multiple lines are running on the SAME machine. BOOT ------------- This is a brutal one. It reboot the machine (warm). You are given 15 seconds to make up your mind. After 15 seconds it is to late and the PC is rebooted. You MUST stay online to make the boot work. If between entering the command and the final countdown the carrier is lost, the boot will NOT take place. Also any key will stop the countdown and will bring you back to the RDS-prompt. Some configurations with DesqView/QEMM and a 386 will hang with the boot, so try it out locally before submitting this command to your remote friends and/or CoSysop(s). VIEWARC ------------- When this command is used with a valid (fully specified filename), the user will get a view of the archive (if it IS an archive) in question. For ZIP/DWC encryption is also marked in the list, for ZIP there is a mark when the file is AV'ed. The VIEWARC command can be used on archives with normal and abnormal extensions and also on all SFX (COM/EXE) self extracting archives. Archive comments are NOT displayed, neither are (absolute or relative) path entries inside the archives. The CRC (for what it is worth) is also NOT displayed. DOWNLOAD ------------- When this command is used with a valid (fully specified filename), the user will be able to start a ZModem download and receive the supplied file. So in the current directory you can download the file A.A with 'DOWNLOAD A.A'. On the RDS side, DSZ <tm> is used, so MobyTurbo <tm> could be available during download; UPLOAD ------------- When this command is used with a valid (fully specified filename), the user will be able to start a ZModem upload and send a file that will be received under the specified name. Multiple upload is NOT available (security !!) and the file is ALWAYS forced to the supplied name (also security !!). Resume is possible. On the RDS side, DSZ <tm> is used, so MobyTurbo <tm> could be available during upload; CHAT ------------- When this command is used, you can chat with any other line (also with yourself, makes fun, doesn't it ?). This function is only present under Remote Access and only when /N is used in the RDS call on the menu-entry. TIMELEFT ------------- This function will display the remaining time. RDS will display the time left for this session. This time is between 1 and 2 minutes less than the actual time because accessing RDS within 2 minutes before the end of the session-time is impossible. BEEP ------------- This command can be used to attract the Sysop's attention. When BEEP is given on the command-line, the Sysop will be bothered with a nice tune of beeps. If she/he wants to chat with you, she/he can enter a message on your command-line (locally) f.i. to exit RDS and to continue chat in a normal chat-door. LOG ------------- If you want to send a message to the Sysop, you can enter LOG with a text and RDS will send this message to the RDS-log. The Sysop can check the log (if she/he does so) and answer you (if needed/wanted) with a message in the BBS. WHERE ------------- With this command you can search the CURRENT drive for a file or a number of files. You must supply a valid DOS-filemask and RDS will search the CURRENT drive for matching files. They are displayed to the user, along with the directory they are in. │MACRO │------------- │See the chapter on macro's, expansion and command stacking. │ │EXPAND │------------- │See the chapter on macro's, expansion and command stacking. SHELL ------------- This is a VERY DANGEROUS command and should only be supplied to users you trust (CoSysop, yourself (?)). SHELL will execute the program you supply as first parameter (you can include drive and path if you want) and uses the parameter(s) (if any) following the programname as calling parameters for this program. There are TWO drawbacks in this command: -1) The called program can not access any input, so the program must be able to execute without user-input. Even a program as PKZIP uses input if you call it with invalid parameters or needs to overwrite files. If RDS calls such a program, the session will hang forever because you can never enter the input for the program. For this reason, RDS will set the FOSSIL-watchdog to ON if a program is called. If the carrier is lost (after the user will hangup the line), the FOSSIL wil reboot the system (please run a test !!!). RDS tries to overcome some minor errors made by the user. If the user enters SHELL PKZIP -A$^&*&(()&^ TEST D*.* (some gar- bage on the line), PKZIP will display it's info and waits for a CRLF to terminate. Before RDS calls the program, 15 times [RETURN] is stuffed into the local keyboard, so PKZIP will (in THIS case) terminate. This will not fix problems like 'Over- write file [y/n]' !!!!!; -2) The called program should not access non-bios (e.g. direct) output. If the program does use direct screen control, the program can be executed, but the results can not be viewed inside RDS. If the programs uses normal standard devices, RDS will display (after termination) the output to the local and remote screen. RDS will route the output of the program to a temporary file (>RDS$$$$$.CAL) and will display this file after the execution is completed; There are several programs that could be very usefull to execute. The archivers (watch out for prompts !!), the fossil driver (XU or some other program), tossing, scanning (these utilities should work unattended, shouldn't they ??) and so on; RDS will always return in the directory it was started from after the user enters EXIT, unless a UserDirectory is active. In this case, RDS will return to the directory that was current when RDS was CALLED ! 3.4 Security ──────────────────────────────────────────────────────────────────────── As you have understand by now, RDS is capable of securing the shell for each and every single user. A few hints to concern about when setting up the security inside the USER-USEREND clusters: - If you want to know everything about what users (or yourself, or the CoSysop) have done, than consider to secure the LOG-file with a ExcludeFile [the log file] option, otherwise these users can cover their deeds by deleting the log or replacing it with a 'dummy' log; - If you want real security, then you must protect the RDS.CTL also. There is nothing more simple than a user (having the COPY feature) to upload a 'customized' RDS.CTL their selfs and to replace the original one with the one of their own. So be warned !!!! - It is a good practice to also secure the RDS.EXE program itself from any ill-behavior. Old chinese wisdom will say: 'If there is a leak, a BBS-user will use it' and also Murphy told us some stories about 'When you are able to accidently delete the RDS.EXE file, it will be deleted'. - Protect personal things unless your CoSysop (or someone else you give RDS features) knows as much about you as you know yourself; - Don't allow your shrink to use RDS. He will find out that the way you set up your directories has something to do with Freud; - If you allow many users directly after you have installed RDS, be sure to have a backup-copy available. Work with a small group of people (at least in the beginning) or use the USER ALL with mini- mal options. - Study the LOG once in a while, and set it to ON in the beginning. In this way you can learn from your friendly CoSysop what to in- clude and what to exclude <grin>. - It is good practice to secure your 'power users' (like those nasty CoSysop's and such people) with a RDS-password. If someone snatches your USERS.BBS (sometimes your USERS.BBS is wide open, check out your bi-directional protocols and such programs) and does a logon under your name or the CoSysop's name, you can be sure that everything is lost EVEN when there is no FORMAT statement in RDS (MOVE, DELETE, RENAME and COPY will do the job just fine); - DON'T give away the SHELL feature. A nice option, but only for the trusted user (SHELL FORMAT C: /U to name one) ! NoShell is default so you must include SHELL for you and your CoSysop in the USER- USEREND cluster !!! │3.5 Macro's, expansion and command-stacking │──────────────────────────────────────────────────────────────────────── │Why not implement wildcard support on those commands that can use it. │This question has to do with security. To keep the memory resources │tight, there are generalized security routines implemented that work │on single files. Also, in a BBS environment, wildcards can be handy │but not used much. Can you see a CoSysop deleting all your files in │one of your directories without having to think about it ? That is │one of the several reasons that only single-file commands are imple- │mented. The security stucture is based on this algorithm, so are the │memory requirements. Implementing wildcards on any command causes a │large algorithm to be triggered to test if every request is valid or │not (imagine something like COPY *.* E:\ZIP\*.ZIP). Besides the pro- │blems with the rename (that part will be implemented in the next │major command) on these 'global' commands like COPY, RENAME and MOVE, │RDS has to check every source and every target to see if this is what │the user is allowed to do. │ │To support wildcards and to implement macros (as available in this │version) in some sort of way, RDS now has a command-stack. Some │basics on this command-stack. │ │Before RDS checks for the next command to be entered by the user, RDS │will check a buffer to see if there is a command (a normal RDS command) │available in this buffer. If it is, RDS wil skip (for now) the next │user-input and starts with this command. When the command is ready, │RDS will delete it from the top of buffer and shift the remainder of │the buffer one place back (FIFO-buffer). This routine stays active un- │til there are no commands left in the buffer (empty buffer). If this │is the case RDS will, as normal, ask the user for input. │Two RDS commands can fill the buffer. These are EXPAND and MACRO. │Each of the commands will add commands to the buffer from the top. │This will always be done with the following algorithm (IMPORTANT, be- │cause this will give you knowledge of how MACRO and EXPAND wil act │when they are nested: │ │In case of buffer-empty: │ │- EXPAND or MACRO knows how many commands are to be added to the │ buffer and will add them from top to bottom; │ │In case of buffer-active (commands in the buffer): │ │- The first thing to know is that the MACRO or EXPAND was already on │ the buffer as a command. The user can not enter into the buffer │ when there are commands in the buffer, so the MACRO or EXPAND was │ already on the buffer; │- EXPAND or MACRO know how many lines to add to the buffer, BUT these │ commands are, again, inserted at the TOP of the buffer. So the │ buffer acts as a LIFO (last in, first out) when a MACRO or EXPAND │ command is taken from the buffer; │- All remaining commands in the buffer (if any) will shift to the │ end of the inserted lines. │ │RDS will check if there is enough room to add commands to the buffer, │but RDS will not take into account if the room is occupied with other │commands. In plain language. If your buffer is 10 lines and there are │5 lines (EXPAND, COPY, COPY, DEL, RENAME for example) and the EXPAND, │that is executed first, will generate 12 new commands, EXPAND will │fail. If EXPAND generates 4 lines, they are inserted at the top, │resulting in the RENAME, DEL and last COPY to be shifted from the │buffer. This last situation is NOT detected by RDS (yet). I will │give an example at the end of this chapter. │ │Now you know that RDS has a command-stack, explaining MACRO is very │simple. You create one (or more) macro-files or the user uses UPLOAD │to upload a macro. The macro-file is a plain ASCII file, containing │a RDS command on each of the lines in the file. An example: │ │COPY TURBO.EXE E:\ZIP │RENAME TURBO.EXE TURBO.BAK │MOVE E:\ZIP\MACRO.EXE │ │This macro contains 3 RDS statements in three different lines. The │macro-file can be as big (but NOT bigger) than the total number of │lines in the buffer (as set with the MacroExpandBuffer option). The │file is called MACRO1.DAT for example. So when you enter the command │MACRO C:\TUP\MACRO1.DAT (or MACRO MACRO1.DAT if the macro is in the │current directory), RDS will read MACRO1.DAT and then execute the │three commands (COPY, RENAME and MOVE) in the order they were in the │macro-file. You CAN nest macro-files as long as you remember not to │overflow the buffer (see example at the end). │ │EXPAND has nothing to do with macro's but act the same. EXPAND also │uses the command-stack in RDS. EXPAND can be used to implement wild- │cards in certain commands. These commands are DEL, TYPE, VIEWARC, │RTYPE, DOWNLOAD, COPY, MOVE and their alias (ERASE, LIST, RLIST). │How EXPAND works can be showed best with an example. You would like │to delete ALL files with *.BAK in the directory E:\ZIP. Normally, │you should use DIR *.BAK and delete every single file. With EXPAND │you use 'EXPAND DIR *.BAK' (without quotes). Now the following things │will happen: │ │- EXPAND will check for all files with that mask in that directory; │- EXPAND will create a command 'DEL filename' for every found file │ in that directory on the command-stack; │- EXPAND will terminate and the command-stack now contains commands │ that will be executed at once. │ │RDS will, as normal, check every single 'DEL' command for valid data. │So if the files TURBO.BAK, RA.BAK and QB.BAK are found (and commands │are generated) and the user is NOT allowed to access files with QB.*, │the 'DEL QB.BAK' will fail and the others will work. RDS will keep │full security on each of the generated commands. │ │There are a few drawbacks in EXPAND: │ │- When used with COPY and MOVE, EXPAND will only work when the target │ is a directory (so no renaming while COPY/MOVE). So the command │ 'EXPAND COPY *.* E:\ZIP\' is valid but 'EXPAND COPY *.BAK *.OLD' │ is invalid (*.OLD is no directory). This drawback will be fixed in │ one of the next majors; │ │- When used with DOWNLOAD, EXPAND will create separate DOWNLOAD com- │ mands, causing ill-behaviour of the command because after the trans- │ mission of a single file, DOWNLOAD is terminated and the next is │ started. This will also be fixed in the next major; │ │EXPAND is a powerfull command and MACRO can also be very usefull. The │combination of both is valid in case of EXPAND commands inserted in- │side a macro file, but not valid in case of MACRO in EXPAND (like │'EXPAND MACRO *.MAC'. │ │Now an example. There are two macro-files (the statements are all │humbug) MACRO1.MAC and MACRO2.MAC: │ │MACRO1.MAC COPY A.A B.B │ MACRO MACRO2.MAC │ TYPE B.B │ │MACRO2.MAC TYPE A.A │ EXPAND COPY *.* E:\ZIP │ │The execution is as follows when MACRO MACRO1.MAC is entered at the │RDS command-line: │ │- COPY A.A B.B │- MACRO MACRO2.MAC (the macro2.mac is INSERTED in the stack) │- TYPE A.A │- EXPAND COPY *.* E:\ZIP (this command generates 2 statements ) │- COPY A.A E:\ZIP\A.A (generated by EXPAND ) │- COPY B.B E:\ZIP\B.B (generated by EXPAND ) │- TYPE B.B │ │Play around with EXPAND and MACRO. The next majors will enhance their │functions again. Last but not least, you can deny the usage of EXPAND │and/or MACRO, just like with all other commands. │ │ │ │3.6 Help file format │──────────────────────────────────────────────────────────────────────── │Up from release 1.20, RDS makes use of only one help file (previous │versions used a help-file per command). You can alter the supplied │example of the RDS.HLP file to your own needs. To do so, you must │understand the basic formats that are used by RDS when reading this │help-file: │ │- RDS read the RDS.HLP file sequential. For speed gain, you should put │ the help-information that is accessed most (e.g. NOT COPY,DEL,MOVE) │ at the start of the file; │- RDS read each line and compares the first 10 bytes (trimmed with │ trailing spaces) with the command you would like to have help on. │ RDS translates some commands. LIST and RLIST are translated to │ TYPE and RTYPE, ERASE is translated to DEL, REN to rename and such │ (look into the original RDS.HLP example-file. It contains all the │ valid commands); │- The next 78 bytes are written to the screen. If you use shorter │ lines, RDS will fill them to 78 bytes, longer lines are truncated │ between the 78th and 79th position; │- Lines containing 'ALL ' in the first 10 positions are always │ displayed (you can use them for headers and such); │- Characters in the first 10 positions must be in uppercase; │- Help-screens are diplayed without pause, so keep the length of the │ help-text inside a logical screen (19 lines) otherwise scrolling │ will be the case; │ │The current help features are extended in the next major release. │This release will probably contain overlays and swapping techniques │to gain memory (for shell, and more new features/commands on RDS) │and some of the memory gain will be used to make the HELP function │more intelligent both to the user and the SysOp. ┌───────┬─────────────────────────────────────────────────────────────┐ │ 4 │ Runtime information │ └───────┴─────────────────────────────────────────────────────────────┘ 4.1 While inside the RDS shell ──────────────────────────────────────────────────────────────────────── RDS works just like a normal DOS-prompt ($P$G) in a regular DOS-envi- ronment. All commands can be entered just like you do while inside the normal DOS-shell. RDS expands the entered items (paths, drives, file) to full pathnames. The only thing you can't work with (at the moment) is with wildcards, so all actions you enter must be done on single files ! To help you with tedious keyboard access when you must copy, move or delete multiple files in long paths, RDS contains a special buf- fer with the last 100 (!) commands you entered. Locally you can recall these commands by pressing the UP-key until you find a command that suits your needs. Remote the UP-key does not work but there you have three other options to recall the commands in the buffer: - By pressing REC or RECALL When you enter REC (or RECALL) you get the previous command (if any) on the command-line. To scroll thru the buffer you must (after each command) clear the line and enter REC again. REC is only useful when you want to recall the LAST command; - By pressing CTRL-E Most users of full-screen message editors will know this command. When you send a CTRL-E from the remote computer, RDS will act the same as with the UP-key on the local computer. Even when the com- mand-line is not empty, pressing CTRL-E will scroll back one com- mand at a time until no more commands (up to 100) are left. This is the preferred method when scrolling back multiple commands; If you don't know anymore which commands can be used with RDS then you should enter ? or HELP to get a display with all available commands. When you enter an empty line, RDS will also remember you to use ? or HELP to obtain all commands on the screen. 4.2 LOG file ──────────────────────────────────────────────────────────────────────── RDS makes a log of almost everything (unless you do not specify the LogPath option in the RDS.CTL). You can always browse thru the log with a normal file-browse utility like Mr. Buerg's LIST. The log-style can be adjusted to the users need with four different options (see the description of RDS.CTL). Also you can combine the log with an existing log-file like the log your mailer produces or the BBS-log. In a multitasking environment (when you loaded SHARE), RDS will serialize the LOG when it has to write to it. This is needed to overcome the problem of trashed log- files or lost clusters when two or more tasks try to write to the same log. Depending on the users actions, the RDS.LOG file can get very large. If you delete your current log-file, RDS will create a new one the next time it is started and finds that there is no log-file anymore. If you allow your users to use the LOG command, it should be advised to make the RDS-logging active, otherwise the users messages will be send into the Twilight Zone. 4.3 Errors ──────────────────────────────────────────────────────────────────────── Every time RDS is started, it will check the options in RDS.CTL. If one or more of the options is invalid, RDS will terminate with a local display (and if the log-file is already known to RDS, by put- ting an entry in the log-file). RDS will also terminate if a user is not allowed to enter the door (no USER-USEREND combination for that user) and when the carrier is lost while RDS is active. RDS will NOT use any watchdog that is present in your FOSSIL. 4.4 Specialized command-line options ──────────────────────────────────────────────────────────────────────── RDS understands some command-line parameters that can (or must) be entered on the call to RDS (inside the menu-entry or a batch file). /CTL[alternate CTL] ------------------- You can use an alternate configuration file. In this case you can add the /CTL command-line option with the path (and name) of the alternate configuration file. /N[line] ------------------- You must specify /N*N on a RA menu entry to enable the CHAT option. RA will substitute the numeric line-number at the location of *N. Under a different BBS, the usage of /N has no meaning. /LOC ------------------- You can run RDS locally (from the DOS-prompt) without the files EXITINFO.BBS and DORINFO1.DEF present when you supply /LOC on the command-line. ┌───────┬─────────────────────────────────────────────────────────────┐ │ 5 │ Version information and credits │ └───────┴─────────────────────────────────────────────────────────────┘ 5.1 The BETA-team ──────────────────────────────────────────────────────────────────────── The following Sysop's and their CoSysop's (only if they use the same BBS or a NON-user (closed) shadow BBS) are allowed to make use of the BETA-releases on their own risk: - Remote Access Multiline/Multiport Paradise 2:512/100 (*) Sysop: Reinier De Groot - GOLEM Service BBS 2:242/4 Sysop: Hanstheo Wolf - Sirex BBS 2:280/216 Sysop: Gerry Ulrich - Funboard BBS Sysop: Dirk Astrath 2:244/12 - Amber Shadow Sysop: Dave Overton 1:203/998 The BBS marked with (*) will always test the newest version and is also the main distribution node for the DISP files. Also mail to me can be send to this system. The other BBS's are asked, if they like, to test the new versions, but if there is no time, or if they find the risk to high I don't mind. I would be pleased though, if these BBS's would like to look into the new BETA version. 5.2 Credits ──────────────────────────────────────────────────────────────────────── Thanks to the following people: - Rob Lirb who told me I couldn't write a simple remote DOS-shell in less than 15 minutes (he was right, it took me 20 minutes). The program you see now, took me somewhat (!) longer than 20 minutes though; - Reinier de Groot for his suggestions on the initial alpha release; - The Beta-team who didn't got a beta-version before version 1.01; 5.3 Version history ──────────────────────────────────────────────────────────────────────── ┌───────┬────────────────────────────┐ │ 1.01 │ First public release │ └───────┴────────────────────────────┘ ■ New release ┌───────┬────────────────────────────┐ │ 1.02 │ Minor release │ └───────┴────────────────────────────┘ ■ Fixed problem with special keys. Users were not allowed to enter key-values in the range 129-255. This is a major drawback for our (amongst others) German and Scandinavian users. The combi- nations must be send to RDS as the key-value, ALT-key-key-key combination as found on the DOS-prompt and some editors is not (yet) implemented. Suggested by: Dirk Astrath ■ Users who tried to TYPE/LIST the RDS.LOG were in for a surprise. RDS would keep the LOG open while TYPE was executed. This is now fixed. Reported by: Dirk Astrath ■ The usage of standard devices AUX, CON, NUL, PRN, LPTx and COMx is now forbidden. This was a big hole in the file access and could cause hangups. Authors modification ■ When displaying HELP, the user got ALL options, also those that were disabled. This is fixed. Users now only get help on the available commands. Reported by: Dirk Astrath ■ The LogPath option is enhanced so multiline users can use different logs per logical line. Suggested by: Dirk Astrath ■ There was an error in the (undocumented) usage of the RDS environ- ment variable. Both documentation and program are fixed. Authors modification ■ RDS can now be called with an alternative CTL-file as an option on the command-line. Authors modification ■ Even if you protect RDS with a security level or when you disable options for special users, you can still secure these users with a special RDS-password. User must (in that case) enter the pass- word within 3 tries otherwise entering RDS is not allowed. Look into the documentation about the USER option. Suggested by: Gerry Ulrich ■ Users who are tired entering new users to RDS.CTL will be pleased with the ALL enhancement. Check out the USER option. Authors modification ■ RDS is now more or less aware of the new RA 1.00 USERON.BBS file. Until this info is official, this will stay 'more or less'. Authors modification ■ Added a new command VIEWARC to view the contents of ZIP, ARC, PAK, PKPAK, LHarc, Larc, MD, DWC, ZOO, LBR archives. Authors modification ┌───────┬────────────────────────────┐ │ 1.05 │ Minor release │ └───────┴────────────────────────────┘ ■ Fixed some problems with EXITINFO.BBS and DORINFO1.DEF files and created a local mode (/LOC); Reported by: Rob Ramselaar ■ Fixed a bug in MOVE (with /D); ■ Removed some duplicate coding; ■ Enhanced the HELP function with a context HELP function; ■ There was no way to create a file (batch-file or something of the kind) inside RDS. The COPY CON [tofile] is now implemented. The user can input characters and/or lines and these are echoed to the [tofile] file. Editing must be terminated with CTRL-Z (both remote and local); ■ Added specific support for only RA and QBBS and/or BBS types that use EXITINFO.BBS and DORINFO1.DEF; ■ Added /N[line] option to support CHAT under Remote Access; ■ Added the RTYPE/RLIST option to read a file reversed; Suggested by: Dieter Baumgartner ■ Added the CHAT function to send messages to other lines under Remote Access. Also messages send to your own line (don't forget /N*N in the menu-call) are echoed to the RDS-screen, so internode chat is available while in RDS; ■ Added the UPLOAD and DOWNLOAD functions so you can upload and/or download a file while inside RDS. This option needs DSZ to perform the transfer. Added the DSZ and DSZParm options in RDS.CTL to support these functions; ■ Added a time-out test in RDS. When the user does not input any character within 5 minutes, RDS terminates. Also carrier is tested everywhere, so the WATCHDOG function is disabled in RDS. RDS will not reboot when the user drops the carrier; ■ Added a test on the remaining time. RDS will terminate 1 minute before the BBS-session will end. Also access to RDS is impossible within 2 minutes before the session ends; Suggested by: Franco Mulato ■ Added the TIMELEFT command to display the remaining session time. ┌───────┬────────────────────────────┐ │ 1.06 │ Minor release │ └───────┴────────────────────────────┘ ■ Fixed an error in the RA (1.xx and up) USERON command. Both message and ul/dl would display as ul/dl. ■ Added the SHELL option and SHELL command in the USER-USEREND clusters. Users can now shell a program such as the archivers and other utilities but under certain conditions; ■ Added the HelpDirectory option for those users who are low in environment space and who can not add the directory containing the *.RDS files to the DOS-path; ┌───────┬────────────────────────────┐ │ 1.10 │ Minor release │ └───────┴────────────────────────────┘ ■ Fixed an error in the UserPassword option. In some cases a user could be prompted for a password while this was not set in the RDS.CTL. In that case a previous USER ALL cluster contained a UserPassword option. ■ Added ARJ and HYPER to the VIEWARC options. Files inside archives of this kind will also be displayed. ■ Added DefaultDirectory option so a user can land in a different directory than the current right from the start; Suggested by: Peter Burnett ■ Added LOG option to let the user write a message to the log; Suggested by: Robert C.L. Lirb ■ Added BEEP option to let the user beep the Sysop (if available); ■ Added WHERE option to search files on the current drive; ■ Added /W to the DIR option to display a condensed listing of the files in a directory. Suggested by: Robert C.L. Lirb ┌───────┬────────────────────────────┐ │ 1.20 │ Minor release │ └───────┴────────────────────────────┘ ■ Fixed a bug in the MEM command. MEM did not show the memory usage of RDS itself. This is fixed. MEM will now give the REMAINING conventional memory. ■ Changed registration; ■ Changed the *.RDS help-files to one new RDS.HLP file, containing all help; ■ Added EXPAND command; ■ Added MACRO command; RDS is tested with several releases of MS/DOS and with Remote Access version 0.04 and 1.00/Cß. 5.4 Copyright, Trademarks ──────────────────────────────────────────────────────────────────────── 4Dos is a trademark of J.P. Software / R.C. Conn and T. Rawson MS/DOS is a trademark of Microsoft Remote Access is a trademark of Continental Software DSZ is a trademark of Omen Technology MobyTurbo is a trademark of Omen Technology DesqView is a trademark of Quarterdeck QEMM is a trademark of Quarterdeck X00 and XU are trademarks of Ray Gwinn RDS is written in Turbo Pascal 5.5, with help of the Turbo Debugger 2.0 and makes extensive use of Object Professional 1.03 and TPCFI 9.04; Turbo Pascal is a trademark of Borland International Turbo Debugger is a trademark of Borland International Object Professional is a trademark of TurboPower Inc. TPCFI is a trademark of Robert W. van Hoeven [---- END OF DOCUMENT ----]